1、日志的功能 用于记录系统、程序运行中发生的各种事件 通过阅读日志，有助于诊断和解决系统故障

2、日志文件的分类 2.1内核及系统日志 由系统服务syslog统一进行管理， 日志格式基本相似 2.2用户日志 记录系统用户登录及退出系统的相关信息 2.3程序日志 由各种应用程序独立管理的日志文件，记录格式不统一

3、日志保存位置 默认位于：/var/log目录下

4、主要日志文件介绍 内核及公共消息日志：/var/log/messages 计划任务日志：/var/log/cron 系统引导日志：/var/log/dmesg 邮件系统日志：/var/log/maillog 用户登录日志:/var/1og/lastlog、/var/log/secure、var/1og/wtmp、/var/run/utmp（记录当前正在登陆系统的用户信息）

5、日志消息的级别 0 ：EMERG (紧急) :会导致主机系统不可用的情况 1 ：ALERT (警告) :必须马上采取措施解决的问题 2 ：CRIT (严重) :比较严重的情况 3 ：ERR (错误) :运行出现错误 4 ：WARNING (提醒) :可能会影响系统功能的事件 1-4级别的需要注意 5 ：NOTICE (注意) :不会影响系统但值得注意 6 ：INFO (信息) :一般信息 7 ：DEBUG (调试) :程序或系统调试信息等

6、与用户信息相关 /var/log/lastlog：最近的用户登录事件 /var/log/secure：与用户验证相关的安全性事件 /var/log/wtmp：用户登录、注销及系统开、关机事件 /var/log/btmp：当前登录的每个用户的详细信息（记录失败的登录尝试信息）

7、分析工具 users、who、w、last（登录成功的历史信息）、lastb（登录失败的历史信息）

1、由相应的应用程序独立进行管理 1.1 Web服 务: /var/log/httpd/ access_ log、error log 1.2 代理服务: /var/log/squid/ access.log. cache.log. squid.out、store.log 1.3FTP服务: /var/log/xferlog

2、分析工具 文本查看、grep过滤检索、Webmin管理套件中查看 awk、sed等文本过滤、格式化编辑工具 Webalizer、 Awstats等专用日志分析工具 通过过滤减少对日志的搜索

1、及时作好备份和归档 2、延长日志保存期限 3、控制日志访问权限 日志中可能会包含各类敏感信息，如账户、口令等集中管理日志 将服务器的日志文件发到统一的日志文件服务器 便于日志信息的统-收集、整理和分析 杜绝日志信息的意外丢失、恶意篡改或删除

实验一：修复MBR扇区故障 1、故障原因 病毒、木马等造成的破坏 不正确的分区操作、磁盘读写误操作 2、故障现象 找不到引导程序，启动中断 无法加载操作系统，开机后黑屏 3、解决思路 应提前作好备份文件 以RHEL6安装光盘引导进入急救模式 从备份文件中恢复 4、应用示例 4.1备份MBR扇区数据 A、创建要挂载的目录 eg：mkdir /backup B、将一个未用的磁盘分区挂载到该目录上（注意不能是sda的） eg：mount /dev/sdb1 /backup/ C、将第一块磁盘sda的MBR扇区备份到刚刚那个未用的磁盘分区上面 dd if=/dev/sda of/backup/sda.mbr.bak bs=512 count=1 4.2模拟MBR扇区故障 dd if=/dev/zero of=/dev/sda bs=512 count=1 从设备文件zero中读取512字节的数据，将其把系统启动设备的数据全部覆盖，从而模拟故障（/dev/zero里面是空白文件将其把/dev/sda设备覆盖从而导致里面的数据丢失实现故障） 4.3 RHEL6光盘引导， 进入急救模式，按提示操作 电源–打开时进入固件–boot中的CD-ROM Drive用shift+加号移至第一位使系统启动时执行进入紧急模式–按f10保存并退出–选恢复操作系统（rescure…） 4.4从备份文件中恢复MBR扇区 A、创建挂载点 eg：mkdir /huifu B、挂载目录 eg：mount /dev/sdb1 /huifu C、恢复数据 dd if=/tempdir/sda.mbr.bak of=/dev/sda bs=512 count=1 注意：要再把之前从镜像启动在恢复到原位 参考网址：https://blog.csdn.net/qq_42298432/article/details/96326896

实验二：修复GRUB引导故障 1、故障原因 MBR中的GRUB引导程序遭到破坏 grub.conf 文件丢失、引导配置有误 2、故障现象 系统引导停滞， 显示“grub>” 提示符 3、解决思路 尝试手动输入引导命令 进入急救模式，重写或者从备份中恢复grub.conf 向MBR扇区中重建grub程序 模拟故障： 把配置文件/boot/grub2/grub.conf破坏掉。在重新启动就是出现故障。 [root@localhost grub2]# mv grub.cfg /huifu（将原有的grub.cfg的数据移动到huifu文件中） 为什么上面的操作会出现故障呢？ 因为grub.cfg是系统可以识别的配置文件，但你把他的文件换一个名字以后系统就识别不了这个配置文件从而无法读取配置文件的数据导致系统不能开机。 修复故障： 法一： 在“grup>”提示符后，手动输入引导命令 例如：第二个grub后输入的是自己虚拟机中grub.conf下的内容 法二：备份然后复制粘贴过去 先cp之前的grub.conf中的内容到一个文件中 进入急救模式，进入“bash-4.1#”的shell环境 #chroot /mnt/sysimage 切换到待修复的linux系统根环境 第一种方法：在linux系统根环境下编写 #vim /boot/grub/grub.conf … 进行编写 #exit 退出chroot环境 #reboot 重启 第二种方法：粘贴之前cp的文件 eg：dd if=/huifu of=/dev/sdb1 bs=512 count=1 //将之前复制到根目录下的文件拷贝到/dev/sdb1中 物理块大小为512kb 数量为1块 法三：在急救模式shell环境重新安装grub引导程序 Eg：将grub引导程序重新安装到第1块硬盘的MRB扇区

1、故障原因 非正常关机、突然断电、设备读写失误等 文件系统的超级块(super-block) 信息被破坏 2、故障现象 无法向分区中读取或写入数据 启动后提示“Give root password for maintenance" 3、解决思路 根据提示输入root口令， 进入修复状态 使用fsck命令进行修复 示例： A、模拟对/dev/sdbl分区的破坏操作 dd if=/dev/zero of=/dev/sdb1 bs=512 cqunt=4 B、检查是否能挂载该分区 mount /dev/sdb1 /mnt/ mount: you must specify the filesystm type C、对/dev/sdb1分区进行修复 fsck y -t ext4 /dev/sdb1 D、再次挂载该分区

1、故障原因 磁盘空间已被大量的数据占满，空间耗尽 虽然还有可用空间，但文件数i节点耗尽 2、故障现象 无法写入新的文件，提示…设备上没有空间” 部分程序无法运行，甚至系统无法启动 3、解决思路 清理磁盘空间，删除无用、冗余的文件 转移或删除占用大量i节点的琐碎文件 进入单用户模式、急救模式进行修复 为用户设置磁盘配额

应用示例 模拟节点耗尽故障 1、新建EXT4文件系统，挂载到/data目录下 #mkdir /data //在根下创建目录data #mount /dev/sdb7 /data //将/dev/sdb7挂载到data下 2、编写并运行测试程序，耗尽/dev/sdb7分区中所有可用的i节点 3、查到该分区中可用的剩余空间 #touch /data/newfile 测试该设备上还有无空间 #df hT /data //确认磁盘空间占用情况

1、故障原因 磁盘设备中存在坏道(逻辑的或物理的) 2、故障现象 读取磁盘中的数据时，磁盘设备发出异常声响。 访问磁盘中的某个文件时，反复读取且出错，提示文件损坏 对于新建立的分区无法完成格式化 系统使用该磁盘时频繁死机 3、解决思路 检测硬盘中是否存在坏道 修复硬盘，或更换新的硬盘 #badblocks -5V /dev/sdb ：检查磁盘是否存在坏道 参考网址：https://blog.csdn.net/qq_42298432/article/details/96326896

补充：查看报错信息，如果不能访问可以到这下面查看 Access_log